home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000809_mvanheyn@cs.indiana.edu _Fri Apr 2 19:36:36 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  4KB
  1. Return-Path: <mvanheyn@cs.indiana.edu>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA20915; Fri, 2 Apr 93 19:36:36 MET DST
  4. Received: from moose.cs.indiana.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA16895; Fri, 2 Apr 1993 19:55:31 +0200
  6. Received: from localhost by moose.cs.indiana.edu
  7.     (5.65c/9.4jsm) id AA09149; Fri, 2 Apr 1993 12:55:29 -0500
  8. From: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
  9. To: www-talk@nxoc01.cern.ch
  10. Subject: Re: WWW access and ensuring confidentiality 
  11. In-Reply-To: Your message of "Fri, 02 Apr 1993 18:06:51 -0000."
  12.              <9304021706.AA20689@manuel.hpl.hp.com> 
  13. Date: Fri, 02 Apr 1993 12:55:28 -0500
  14. Message-Id: <9145.733773328@moose.cs.indiana.edu>
  15. Sender: mvanheyn@cs.indiana.edu
  16.  
  17. Thus wrote: Dave_Raggett
  18. >Here at Hewlett Packard, we need a way of preventing unauthorised
  19. >access to information, but want to take advantage of the WWW for
  20. >sharing information with colleagues.
  21. >
  22. >Please give me your comments on our proposed solution.
  23. >
  24. >I am working on a solution that makes use of UNIX's established
  25. >security mechanisms and making it easy for non-technical types
  26. >to manage things for themselves without the need to call out
  27. >the support staff.
  28.  
  29. I've thought about implementing something like this, and I think
  30. that's a reasonable starter solution.
  31.  
  32. (I'm sure you know all this already, but I'll mention it anyway...)
  33.  
  34. - If you want more than token security, passwords flying around the
  35.   network in the clear is obviously a Bad Thing.
  36. - Since the data is passed across the net in the clear, disclosure
  37.   protection may or may not be attained; it depends whether this is
  38.   going on a LAN or a WAN or what.
  39.  
  40. Kerberos type models are possible, but I don't think the current HTTP2
  41. standard could work with kerberos (I believe this would require a
  42. fundamental change in the request-response to something like
  43. request-challenge-reply-response, which is a big change.  Or am I
  44. recalling the changes to version 5 incorrectly?)
  45.  
  46. Ultimately, the general solution should be simple enough; since we're
  47. already using MIME mail-like mechanisms for content identification,
  48. once MIME and PEM are made interoperable (standards should be out
  49. soon), you can have signed PEM (or PEM-like) requests and encrypted
  50. responses.  There would be some trickiness, since the headers of the
  51. response message are among what needs to be authenticated.  The bad
  52. part is that PEM isn't here today, and may not be here any time
  53. particularly soon.  But it's obviously the right solution in the long
  54. run, particularly since the certification hierarchy would allow the
  55. kind of legal mechanisms for non-deniability of origin and disclosure
  56. protection that would be highly desirable for, say, a publisher to
  57. make copyrighted works available via WWW for a modest fee.
  58.  
  59. Since I'm already posting to the list, anyone who is in the process of
  60. trying to write a WWW server in perl may wish to glance at a brief
  61. commentary in http://cs.indiana.edu/perl-server/intro.html that I
  62. made; this includes some discussion of the design guidelines involved
  63. in its creation (which are probably rather controversial) and the
  64. code.  It's not code that you can just pop in and run on your machine,
  65. but your friendly neighborhood perl hacker might find it interesting
  66. to look at.
  67.  
  68. - Marc
  69. --
  70. Marc VanHeyningen   mvanheyn@cs.indiana.edu   MIME & RIPEM accepted
  71. In fact, if you live in the USA, and you are not a Federal agency, you
  72. shouldn't actually run PGP on your computer.
  73.         - Phil Zimmermann